feat: add private payment requests - #1172

Back stack loses ReceiveRoute.QR when the sheet opens at a non-QR route.

Replacing LaunchedEffect(startRoute) { navController.navigateTo(startRoute) } with startDestination = startRoute means QR is no longer the root of the inner NavHost stack.

ContentView.kt:936 (FundingScreen -> "Fund") opens Sheet.Receive(route = ReceiveRoute.Amount). In that flow:

1. ReceiveAmountScreen's onBack = { navController.popBackStack() } now returns false — the back arrow is a dead control.
2. ReceiveRoute.Confirm's onContinue does navigateTo(QR) { popUpTo(QR) { inclusive = true } }. With QR absent, the popUpTo is a no-op and the stack becomes [Amount, Confirm, QR], so back from the QR screen lands on Confirm instead of closing the sheet.

Duplicate payment request via system back.

onSent navigates to PaymentRequestSent without popping PaymentRequestRecipient, and navigateTo only sets launchSingleTop. The Sent screen has no BackHandler or back arrow, so system back returns to the recipient picker with selectedTarget still set and isCreating == false — "Send Request" is enabled and proposes a second request for the same draft.

Suggest popUpTo(ReceiveRoute.PaymentRequestRecipient) { inclusive = true }.

Dropping firstError = firstError ?: it silently swallows total publication failure.

This hunk removes the firstError assignment, so a receiverPathSelection.error is now only logged, never propagated.

If selection fails for every contact, publicationReceiverPaths is empty, so preparation.updates.isEmpty() and the if (requireImmediatePublication) preparation.firstError?.let { throw it } guard sees null and returns success. The requireImmediatePublication = true callers — ContactPaymentSettingsRepo.kt:49, :79, :148, the "share private payment details" toggles — then report success to the user while nothing was published.

eligibleTargets now issues remote lookups on every refresh().

It runs from synchronizeLocked, and per saved contact does paykitReceiverPaths(publicKey) plus a paykitReceiverMarker(publicKey, path) remote read. refresh() is driven by startInitialPaykitPaymentRequestPolling (15 runs at 2s intervals, re-armed on every initial link burst) and then by the 30/60/120s poll loop.

With N contacts that is roughly 15 x N x 2 remote reads inside 30s, on a path that previously only listed local records. Worth caching per identity/generation or computing it off the refresh path.

Automatic presentations now retry forever.

The give-up branch above only applies when requestedPaymentRequestId == request.id. For a non-requested (automatic) presentation, once PAYKIT_PAYMENT_REQUEST_PRESENTATION_RETRY_DELAYS (now List(14) { 2.seconds }) is exhausted, attempt saturates at 14 via coerceAtMost and retryDelay falls back to PAYKIT_PAYMENT_REQUEST_REFRESH_INTERVALS.last() (120s) indefinitely.

An incoming request whose private payment details never resolve calls beginPaymentRequest every 2s for ~28s, then every 2 minutes for the request's whole lifetime (up to 30 days). The previous code stopped after 4 attempts.

Related: the requested-branch return at line 869 leaves paymentRequestPresentationRetryAttempts[request.id] at its saturated value. A later "Pay" tap on the same request therefore gives up on its first failure — no retry window, no "waiting for details" toast, and the log misreports the attempt count.

Store can never repair a corrupt entry.

Both load (line 28) and save (line 35) call Json.decodeFromString<State>(...) on the raw keychain value with no fallback. If that entry is ever corrupt, or written by a future/older schema, load throws (callers swallow it and see an empty set) and every subsequent save throws too — so the bad value is never overwritten.

Effect: presented-request ids stop persisting permanently, and already-surfaced payment requests are auto-presented again on every app start. save should treat a parse failure as State() and overwrite.

Reject runs in the card's rememberCoroutineScope().

scope is rememberCoroutineScope() from PaymentRequestCard (line 456), so it is tied to the card's composition. onReject is a suspend () -> Result<Unit>; closing the sheet mid-flight cancels it, which can leave the request rejected in the SDK but still shown as pending (and the outbound message unflushed) until the next refresh.

createPaymentRequest already runs this kind of work in viewModelScope; same is warranted here.

Pasting an unknown pubky gives a blank screen with no explanation.

The field is labelled "RECIPIENT" with placeholder "Enter pubky" and a Paste button, but query only filters targets, which are derived from saved, linked contacts. Pasting a valid pubky that is not already a saved and linked contact yields an empty recipients list with no message, so the user cannot tell why the recipient is unusable.

Worth an empty-state explaining that the recipient must be a saved contact with private payment details linked.

Dead parameter, and it is not part of the remember key.

showSymbol has no callers — both existing call sites omit it.

If it is kept, line 34 is a problem: if (showSymbol == null) rememberMoneyText(sats) else rememberMoneyText(sats, showSymbol = showSymbol) creates two distinct composable call sites, so toggling it at runtime discards remembered state. More importantly rememberMoneyText keys on remember(currencies, sats, unit) — showSymbol is not a key, so a future caller that flips it for the same sats/unit gets the stale string.

Either drop the parameter or add showSymbol to the remember key.

Three new entries are out of alphabetical order (CLAUDE.md: "ALWAYS add new localizable string resources in alphabetical order in strings.xml"):

• wallet__payment_request_sending (this line) sorts before wallet__payment_request_sent_*, not after
• wallet__payment_request_waiting_for_details (line 1209) sorts before wallet__payment_request_waiting_for_recipient
• wallet__payment_requests_earlier (line 1213) sorts before wallet__payment_requests_empty_*